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SECTION  I 


INTRODUCTION 


BACKGROUND 

Most  non-dedicatea  systems  have  security  provisions 
that  grant  approved  users  access  to  the  system*  and  then 
only  for  non- prohi b i ted  purposes  within  previously  speci- 
fied limits  on  the  resources  consumed*  These  security 
provisions  are  intended  to  ensure  that  no  user  can  access 
private  data  or  system  data  unless  he  has  Been  granted 
sufficient  access  privileges  by  someone  with  proper 
authority.  These  provisions  are  further  intended  to 
protect  the  system  Integrity  from  attacks  such  as  a user’s 
attempt  to  deny  services  to  others*  to  increase  his  own 
orivi  leges*  or  decrease  his  own  costs. 

Most  systems  contain  audit  and  surveillance  subsys- 
tems intimately  linked  to  these  security  and  integrity 
functions.  They  serve  generally  to  record  data  concerning 
such  events  as  all  successful  (and*  often,  all  unsuc- 
cessful) logins,  al  I creations  and  most  recent  modifica- 
tions of  files,  and  all  granting  ana  rescinding  of  access 
privileges  to  the  protected  data  files. 

Somewhat  aside  from  these  security  and  integrity 
considerations*  the  oerformance  of  the  system  is  usually 
heavily  monitored*  e.g.,  records  ere  maintained  of  the 
occurrence  of  crashes*  their  nature  (whether  due  to  hard- 
ware or  software),  the  percentage  of  CPU  util  izatior,  the 
on-line  vs.  batch  consumption*  and  system  reconfigurations 
(whether  dynamic  or  off-line)  in  response  to  component 
failures.  Such  surveillance  often  serves  a limited  oublic 
function*  as  in  the  orovision  to  all  users  of  such  infor- 
mation as  the  number  of  present  users*  the  current  system 
load*  the  time  of  the  last  crash,  and  the  identity  of  the 
other  users. 


MULTI-LEVEL  SECURE  COMPUTING  SYSTEMS 

Before  we  go  on  to  discuss  security*  and  the  audit 
ana  surveillance  mechanisms  that  are  aooropriate  in  a 
multi-level  secure  environment,  a use  of  audit  and 
surveillance  that  is  sometimes  proposed  should  be  immedl- 
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ately  discredited.  It  has  been  suggested  that  audit  and 
surveillance  can  be  used  to  provi de  system  security.  It 
should  be  apparent*  however*  that  if  you  Know  enough  about 
access  control  to  list  all  accesses  (audit)  or  detect  when 
an  access  is  about  to  happen  (surveillance)*  then  you  Know 
how  to  prevent  the  access  in  the  first  place.  Thus*  the 
discussion  that  follows  will  address  an  environment  in 
which  a security  Kernel  provides  effective  access 
controls*  and  audit  and  surveillance  appropri ate  I y augment 
these  controls. 

Military  security  policy  til  regulates  the  handling 
of  classified  information.  It  requires  and  sets  rules  for 
the  assignment  of  personal  responsibility  for  document 
classification*  the  clearance  of  individuals  for  access 
privileges  to  information  of  varying  security  levels*  the 
accounting  of  responsibility  for  individual  documents  and 
the  modes  and  conditions  under  which  such  documents  can  be 
transferred.  This  policy  further  serves  to  give  a formal 
meaning  to  the  word  “security**  that  can  and  must  be  trans- 
lated into  the  context  of  computer  systems  that  process 
data  bearing  military  classification.  The  application  of 
security  policy  to  electronic  data  processing  gains  a new 
dimension  of  significance  with  the  advent  of  multi-level 
secure  systems*  i.e.*  computer  systems  that  support  facil- 
ities for  the  simultaneous  servicing  of  users  with  varying 
security  clearances  accessing  shared  data  of  varying  secu- 
rity classification. 

Examples  of  multi-level  systems  currently  constructed 
or  under  construction  are  the  Multics  System  at  the  Air 
Force  Data  Services  Center  C 2 1 * the  Security  Kernel  Based 
Multics  System,  the  Prototype  Secure  Front  End  Proc- 
essor [3],  the  POP- 1 1/45  Security  Kernel  at  The  MITRE 
Corporation  [4],  and  systems  unoer  development  such  as 
SATIN  IV  and  some  upgraded  versions  of  the  AABNCP.  The 
extreme  sensitivity  of  classified  military  data*  combined 
with  the  tenable  assumption  of  an  espionage  agent  having 
large  available  resources*  places  much  higher  demands  on 
the  credibility  and  demons trab i 1 1 ty  of  security  in  such 
systems  than  is  normally  placed  on  those  “secure**  systems 
constructed  for  civilian  applications.  These  demands  have 
led  to  the  development  of  a technology*  based  on  the 
concept  of  a reference  monitor  [5]  that  monitors  all 
references  to  information*  is  tamperproof  and  can  be 
proven  correct. 


The  Muftlcs  system  was  recognized  as  a viable  candi- 
date to  support  multi-level  security  controls  quite  early 
In  the  Air  Force  program.  In  fact,  an  early  evaluation  of 
this  machine  by  Anderson  [6]  contained  an  appendix  that 
addresses  the  utility  of  audit  in  such  a system.  In  the 
discussion  that  follows,  many  of  the  observations  are 
directed  towards  the  computat iora I environment  provided  by 
Mu  I tics. 


IMPACT  ON  AUDIT  AND  SURVEILLANCE 

OoO  5200. 28-M,  "Techniques  and  Procedures  for  Imple- 
menting, Deactivating,  Testing,  and  Evaluating  - Secure 
Resource  - Sharing  AOP  Systems",  contains  a section  on 
audit  that  we  reproduce  in  its  entirety! 

SECTION  V 
AUDIT  LOG  OR  FILE 

5-10  0 HOfllicaliSO 

An  audit  log  or  file  (manual,  machine,  or  a 
combination  of  both!  shall  be  maintained  as 
a history  of  the  use  of  the  ADP  System  to 
permit  a regular  security  review  of  system 
activity.  (e.g..  The  log  should  record 
security  related  trans  actions,  inducing 
each  access  to  a classified  file  and  the 
nature  of  the  access,  e.g.,  logins,  produc- 
tion of  accountable  classified  outputs,  and 
creation  of  new  classified  files.  Each 
classified  file  successfully  accessed 
<regardless  of  the  number  o*  individual 
references>  during  each  "Job”  or  "interac- 
tive session"  should  also  be  recorded  in 
the  audit  log.  Much  of  the  material  in 
this  log  may  also  be  required  to  assure 
that  the  system  preserves  information 
entrusted  to  it.) 

This  security  manual  is  adaressed  to  data  processing 
systems  in  general,  not  Just  on-line  mu  1 1 1-se cur  1 1 y- I eve  I 
systems  and  much  of  the  above  oaragrach  would  be  equally 
applicable  to  single-level  systems.  While  the  audit 
requirements  outlined  i mo  I y a minimum  capability  that  must 
(and  which,  for  many  systems,  can  easily)  oe  supplied,  we 
must  inquire  whether  multi-level  security  does  not  carry 
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much  broader  imo llcations  for  audit  and  surveillance* 

While  our  response  to  the  above  question  is  certainly 
affirmative*  we  do  not  feel  that  it  is  possible  to  iden- 
tify* at  this  time*  the  additional  facilities  required  or 
those  that  are  cost  effective  for  multi-level  systems. 

The  primary  purpose  of  tnis  report  is  to  outline  some  of 
the  more  prominent  issues  in  audit  and  surveillance*  and 
to  identify  a reasonable  course  of  action  to  address  these 
issues.  Nonetheless*  it  does  strike  us  that  the  general 
tone  of  the  appropriate  response  mill  depend  sharply  on 
one  critical  distinction,  viz,  whether  me  are  dealing  with 
3 system  engineered  for  security  or  one  whose  security  has 
been  mathematically  demonstrated. 

Sfccuce_Systeffls_ln  CQQirall^H-EQylcpmngQls 

A secure  system  in  a controlled  environment  is  one 
designed  to  protect  against  compromise  of  information  in  a 
multi-level  environment,  but  which  has  not  been  subject  to 
a thorough  mathematical  validation.  Such  a system  will  be 
called  a plausibly  secure  system.  The  Air  Force  Data 
Service  Center  System  121  is  an  example  of  such  a system. 
For  these  systems*  we  imagine  that  a quite  significant 
role  would  be  played  by  surveillance  for  the  purpose  of 
detecting  user  behavior  that  might  indicate  a breach  in 
security  or  an  attempt  at  such  a breach.  Such  surveil- 
lance might  even  lead  to  the  timely  arrest  of  an 
implicated  partner  or  author  of  a malicious  “Trojan  horse” 
[7]  procedure.  These  techniques  may  even  extend  into  more 
active  entrapment  strategies  for  such  arrest  or,  at  least, 
the  channeling  of  such  attempts  into  Innocuous  pathways. 
Audit  may  be  used  for  the  estimation  of  the  likelihood  of 
prior  damage  due  to  successful  penetration  attempts* 
hopefully  with  some  indication  of  those  data  areas  dost 
likely  compromised. 

A demonstrably  secure  system  has  had  its  security 
controls  demonstrated  (mathematically  proven!  to  be  effec- 
tive. In  such  a system,  individual  responsibility  can  be 
reliably  enforced.  In  these  systems  we  would  not  want  to 
imply  that  all  the  surveillance  considerations  associated 
with  non-verified  systems  disappear.  There  will  always  be 
someone  who  has  sufficient  reservations  to  suggest  that  it 
cannot  hurt  to  apply  such  techniques*  especially  if  they 
have  already  neen  developed.  Furthermore*  tnere  may  well 
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remain  a would-be  penetrator  who  thinks  he  might  be  able 

to  subvert  the  protection  mechanisms  and  who  tries  Ms 
hand  at  It.  He  should  be  prepared  to  apprehend  him. 

However*  there  may  turn  out  to  be  a novel  use  of  an 
audit  facility  in  conjunction  with  a demonstrably  secure 
multi-level  system  in  which  the  audit  serves*  In  effect* 
not  simply  to  record  the  functioning  ot  the  system*  but* 
rather  interestingly*  to  enhance  it.  This  possibility 
stems  from  the  methodology  by  which  such  certifiable 
systems  as  the  POP-n/45  Kernel  [4]  or  the  Multics  kernel 
are  designed  and  validated.  In  these  systems*  the  memory 
is  a virtual  one*  divided  into  segments  each  of  which 
bears  a security  level.  All  memory  references  are 
localized  to  and  monitored  by  a security  kernel  that 
guarantees  that  security  is  preserved  by  the  imposition  of 
a sufficient  condition*  called  the  "♦ -propert y”  [8].  The 
♦-property  provides  the  assurance  that  no  process  can 
write  data  at  a lower  classification  than  the  maximum 
level  it  is  entitled  to  read.  Now,  while  the  ♦-property 
provides  an  adequate  basis  for  the  construction  of  a 
demonstrably  secure  multi-level  system,  it  may  be  possible 
to  relax  this  sufficient  access  check.  The  check  would  be 
relaxed  in  that,  if  the  ♦-property  were  to  be  violated  on 
an  access*  then  the  access  woulo  be  enabled*  but  audited. 

A permanent  record  would  then  be  kept  of  al I such 
♦-property  violations. 

In  essence,  the  user  would  be  empowered  to  make  the 
same  decisions  he  is  empowered  to  with  respect  to  paper 
documents.  The  essential  r ole  of  the  audit  is  to  provide 
a record  of  any  advantage  a "Trojan  horse"  might  have 
taken  of  the  relaxation  of  this  access  rule.  This  novel 
significance  of  this  audit  technique  is  discussed  at 
greater  length  in  Section  II*  under  the  title*  "FUNCTIONAL 
AUDITING".  Of  course*  audit  provides  the  accountability 
for  need-to-know  controls. 


PURPOSE  AND  OUTLINE  OF  THIS  REPORT 

The  purpose  of  this  report  is  to  serve  as  a guideline 
for  ESO  in  planning  the  audit  and  surveillance  of 
mu  I 1 1- secur  1 1 y- I eve  I computer  systems.  Special  emphasis 
is  placed  on  the  secure  computer  systems  being  developed 
under  ESO  direction.  We  intend  this  report  to  be  avail- 
able as  both  an  introduction  to  the  Issues  involved  in  the 
audit  and  surveillance  of  such  systems  and  as  a partial 
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checklist  for  the  direction  and  monitoring  of  anyone 
developing  such  facilities. 


Ii 


Following  this  introduction*  Section  II  discusses  the 
purposes  and  goals  of  audit  and  surveillance  of  multi- 
level computer  systems.  Section  III  discusses  the 
constraints  that  might  be  imposed  on  audit  and  surveil- 
lance strategies*  e.g.«  cost  corstrairts  or  conflicts  with 
privacy  or  integrity  considerations.  Section  IV  lists  a 
number  of  "strategies"*  l.e.«  approaches  that  might  be 
taken  both  to  the  provision  of  audit  and  surveillance 
functions  within  multi-level  secure  computer  systems  ana 
to  the  study  program  that  might  clarify  those  surveillance 
approaches  that  seem  most  sound  and  cost-effective. 
Finally*  Section  V presents  a set  of  recommendations  to 
ESD  as  to  what  we  feel  represents  a reasonable  course  to 
oroceed  along  with  respect  to  the  stucy*  development*  and 
implementation  of  audit  and  surveillance  sub-systems  of 
on-line  mu  I ti-secur i ty- I e ve I computer  systems.  These 
range  from  the  immediate  provision  of  "statutory"  audit 
facilities  to  the  teas  .i’.'ty  study  and  perhaps  eventual 
installation  of  some  or  ti  j more  imaginative  surveillance 
proposals. 


SECTION  II 


GOALS 


THE  MECHANICS  OF  OATA  CLASSIFICATION 

To  speak  of  the  preservation  of  security  in  a 
computer  system  implies  the  presence  of  certain  minimal 
facilities*  In  particular  each  user  must  have  a known 
security  level,  i.e.»  the  maximum  level  (1>  of  the  process 
he  can  invoke?  each  orocess  must  have  a security  level* 
i.e.*  the  maximum  security  level  of  data  it  can  reaa  and 
the  minimum  it  can  write?  and  each  data  structure  must 
have  a security  level*  In  practice*  a good  deal  more  is 
usually  present.  Each  user*  for  examcle*  not  only  has  an 
associated  security  level  known  to  the  machine*  but  also  a 
password*  certain  project  associations  and*  though  often 
physically  or  logically  associated  with  the  data*  certain 
access  privileges  to  data  segments  --  essentially  the 
embodiment  of  the  "need-to-know"  policy*  He  often*  of 
course*  has  further  properties  such  as  (in  Multlcs)  a 
"user  profile'*  or  resource  guotas  that  do  not  currently 
concern  us.  There  must  be  a mechanism  by  which  the  user 
is  granted  these  properties*  some  presumably  by  himself 
(passwords! » some  by  the  "system  security  officer"  (secu- 
rity level)*  and  some  by  his  "prolect  officer"  (project 
association).  After  this*  each  user  must  have  available 
the  mechanisms  of  security*  i.e**  the  ability  to  create 
processes*  to  assign  them  security  levels*  and  then  to 
direct  these  processes  to  create  data  structures  and 
assign  them  security  levels*  all  of  course  consistent  with 
the  security  policy. 

STATUTORY  AUDITING 

Up  to  this  point,  the  function  of  audit  is  basically 
"statutory",  i.e.,  in  consonance  with  OoO  Security  Manual 
52CG»2fl"M.  A log  must  be  maintained  that  Includes  a 


(1)  Security  level,  here,  may  be  interpreted  to  Include  a 
formal  access  category,  as  well  as  a "clearance".  All 
that  is  needed  to  implement  such  a policy  is  to  Impose  a 
partial  ordering  on  the  ordered  pairs  of  security  levels 
represented  as  <cl assi f ic at  ion, category >. 
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record  of  each  login*  each  creation  of  a classified 
ture,  each  granting  of  access  rights  to  same*  each 
transfer  of  ownership  of  same*  each  modification  of  same* 
each  access  to  same*  each  destruction  of  same*  and  each 
production  of  classified  output.  Output  is  generally 
thought  of  as  printouts*  punched  cards*  magnetic  tapes* 
and  disks  if  these  are  distinguishable  from  virtual  memory 
[9].  Perhaps*  in  systems  in  which  several  active  user 
processes  may  share  access  to  the  same  data  structure*  the 
wora  "output"  is  to  be  extended  to  data  structures  created 
(modified)  by  a process  but  for  which  it  can  no  longer 
guarantee  control  or  integrity.  The  most  troublesome 
"output"  however*  might  be  terminal  output  for  which  the 
only  secure  accounting  method  may  have  to  be  premised  on 
severe  ohvslca I security  restr ict  iors  . 

Needless  to  say*  for  many  surveillance  purposes*  the 
recording  of  all  unsuccessful  attempts  at  logglng-ir  or 
data  accessing  and  the  reesons  they  were  denied  may  prove 
more  interesting  than  that  of  the  successful  ones  required 
by  OoO  directive.  In  all  probability*  however*  the  unsuc- 
cessful attempts  that  represent  malicious  (and  hence  more 
interesting)  behavior  will  be  cluttered  by  entries  caused 
by  incompetence*  curiosity*  or  skeptical  users.  Thus 
tools  must  be  develooeo  to  aid  in  the  recognition  of  mali- 
cious behavior. 


FUNCTIONAL  AUOITING 

As  we  mentioned  in  SECTION  I*  we  foresee  that 
auditing  will  serve  mul ti -secur  ity- I eve  I computing  systems 
not  simply  by  keeoing  records  of  the  legitimacy  of  their 
operation  but  also  by  extending  their  capabilities  and 
services.  These  extensions  derive  basically  from  circum- 
stances in  which  the  fudgement  of  the  authorized  users  and 
the  system’s  security  officer  concur  that  it  would  be 
appropriate  to  functior  within  an  established  exceptional 
orotocol  that  permits  deviation  from  the  normal  validated 
security  provisions. 

One  such  circumstance  might  arise  from  the  occurrence 
of  a bug  in  an  unclassified  utility  program  that  cannot  be 
caused  to  manifest  itself  except  when  the  orogram  Is  oper- 
ating on  classified  data.  It  Is  not  difficult  to  build 
scenarios  in  which  the  requirement  that  the  final  debugged 
version  stored  as  part  of  the  ystem  software  never  had 
the  opportunity  to  read  class!  led  data  would  serve  to  set 
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up  such  tortuous  sequences  of  logins  and  logouts  as  to 
impede  the  effective  employment  of  the  interactive  oebug- 
ging  facilities  provided  by  the  on-line  development.  The 
problem  becomes  more  severe  should*  as  might  happen  in  the 
case  of  system  software  proviaeo  by  the  computer 
manufacturer*  there  be  no  personnel  with  clearance  at  the 
security  level  of  the  offending  data  sufficiently 
conversant  with  the  code  to  debug  the  program 
efficaciously. 

Similar  operational  problems  might  arise  in  the 
sanitization  of  documents.  We  are  referring  here  to  the 
process  of  extracting  unclassified  sections  from  a classi- 
fied document  in  order  to  prepare  a version  for  wider 
distribution.  An  example  of  sanitization  has  been  consid- 
ered by  Stork  [10]  in  a project  that  looked  at  the 
operations/ inte 1 1 igence  interface.  Ocwngradlng  poses  no 
problem  should  the  original  document  be  composed  of 
several  segments  (files)  with  no  classified  segment  (file) 
containing  unclassified  data  we  wish  to  Include  in  the 
sanitized  version.  However*  such  a clean  segmentation  of 
the  data  presupposes  much  foresight  and  care  on  the  part 
of  the  author  and  supportive  software  on  the  part  of 
computer  facility. 

All  these  problems  come  to  a head  in  the  case  th3t  we 
wish  to  downgrade  information*  l.e.*  to  take  information 
that  had  once  been  assignee  a high  security  level  and  now, 
because  of  changed  circumstances*  reass  lgn  it  a new, 
lowered  security  level. 

For  this  downgrading  to  happen*  obviously  both  an 
author  and  the  security  officer  must  assume  responsi- 
bility. In  the  ordinary  downgrading  or  sanitization  of 
paper  documents,  the  author  must  read  the  document  care- 
fully so  as  to  take  responsibility  for  the  security  level 
of  Its  contents.  Naturally*  the  same  would  be  reauired 
for  the  release  of  data  contained  lr  a 

mu  I 1 1-secur i ty- I eve  I computer  system.  We  would  certainly 
require  the  author  to  obtain  a printout  of  the  cocuwent  In 
question  and  to  Inspect  it  carefully.  But  there  is  a 
limit  to  what  can  be  exoected  of  any  human.  Can  we  hold 
him  responsible  for  every  ron-printab  le  character  that 
could  not  show  up  in  that  printout*  every  least  signifi- 
cant digit  in  every  table,  for  the  number  of  soaces  sepa- 
rating each  pair  of  sentences?  Obviously  not.  Yet,  each 
of  these  is  a possible  coramun ic at  1 or  channel  by  which  a 
Trojan  horse  could  take  advantage  of  the  reclassification 
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event  to  transmit  data  from  classified  segments  to 
unclassified  ones. 

In  order  to  make  these  mechanisms  for  exceptional 
operations  available*  Me  must  support  them  with  a variety 
of  audit  software  tools.  It  is  this  support  that  we  are 
referring  to  as  "functional  auditing".  At  the  leest*  we 
would  expect  trusted  programs  that  could  perform 
bit-by-bit  comparisons  of  "before  and  after"  segments  or 
portions  of  segments  and  which  can  preserve  before  and 
after  segment  versions  for  investigative  purposes*  should 
any  doubts  arise  in  the  future. 

To  be  more  specific*  the  following  sequence  of  events 
is  likely  in  the  movement  of  information  from  one  security 
level  to  a lower  security  level.  First  the  owner  lor 
author)  of  the  document  composes  the  information  to  be 
downgraded.  A request  is  then  made  external  to  the 
computer  system  (phone*  letter,  etc.)  for  specific 
downgrading  action  by  the  System  Security  Office  (SSO). 
9oth  the  SSO  and  author  would  then  compare  the  document 
before  and  after  downgrading  to  Insure  that  the  "after" 
document  was  the  same  as  the  before. 

Thus*  by  providing  a set  of  aualt-llke  functions,  it 
may  be  possible  to  facilitate  the  user  interface  ana  to 
allow  for  the  sanitization  and  downgrading  of  information. 


PROTECTING  AGAINST  THE  TRUSTED  USER 

The  OoO  policy  for  personnel  security  specifically 
addresses  the  establishment  of  levels  of  security  for  an 
Individual  (by  "measuring"  the  Individual’s  trustworthi- 
ness). In  the  event  that  a user  breaches  his  trust,  the 
audit  log  provides  individual  accountability  for  access  to 
information.  Such  protection  against  the  trusted  user  is 
even  more  significant  in  ron-DoO  systems  where  policies 
for  placing  trust  are  not  well  established  and  the  trusted 
user  becomes  a more  serious  threat.  It  should  be  noted* 
however*  that  as  audit  is  used  more  as  a part  of  the  secu- 
rity mechanism,  more  effective  tools  for  dealing  with  the 
audit  log  must  be  developed. 
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CONTINUAL  HARDWARE  AND  SOFTWARE  MCNIT  CRING 


A security  Kernel  is  depenoent  on  both  hardware  ana 
software  for  its  complete  mediation  of  all  data  refer- 
ences* Clearly*  no  system,  no  matter  how  complete  the 
verification  of  its  programs*  can  be  guaranteed  secure  in 
the  face  of  hardware  failures  that  effect  its  very  protec- 
tion mechanisms.  It  is  therefore  necessary  to  have 
present  a program  that  continually  exercises  the  hardware 
elements  that  support  the  security  control  mechanisms. 

This  program  is  often  referred  to  as  "the  subverter"  [11]. 
The  subverter  is  a hardware  surveillance  mechanism  that 
provides  protection  against  the  probabilistic  failure  of 
the  hardware.  The  subverter  can  be  IrvoKed  at  regular 
intervals  to  provide  ary  specific  value  for  the  mean  time 
between  security  failure  ( 2 ) . Inci dent al I y , it  is  necessary 
to  have  a mechanism  to  turn  off  the  audit  function  for 
this  subverter  program.  Otherwise*  our  susDiclous 
behavior  log  would  fast  be  saturatea. 

While  the  subverter  program  is  an  obvious  necessity, 
it  is  not  entirely  adeauate  as  a protection  against 
hardware-based  security  compromise.  Because  it  cannot 
exhaustively  test  the  harcware,  the  subverter  may  not  find 
a well  placed  trapdoor,  although  it  may  find  an 
accidentally  placed  one  (see  Karger  and  Schell’s  [12] 
experience  with  Hultics). 

Another  possibility  for  "de-va I 1 dat ion"  of  a verified 
system  is  that  the  proof  of  security  may  depend  not  only 
on  hardware  reliability  but  also  on  the  correctness  of 
certain  actions  on  the  part  of  the  operator,  e.g.«  the 
setting  of  switches  or  the  typing  of  parameters  when 
initializing  the  system.  It  would  be  best  if  this  were 
not  the  case.  If  it  proves  impossible  to  avoid,  redundant 
controls  could  minimize  the  danger  and  the  oarameter 
settings  could  be  entered  In  the  audit  log. 


(2>  A araft  Honeywell  study  [3]  attempts  a rough  estimate 
of  these  probab i I i t i as.  For  a specific  system  measured, 
the  mean  time  between  failure  is  7100  hours  and  the  mean 
time  between  security  failure  is  1,920.000  hours. 
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DETECTION  OF  PENETRATION  ATTEMPTS 

One  way  often  suggested  to  safeguard  data  Is  to  try 
to  catch  the  would-be  penetrators  in  f I a a ra  n t e de  llcto. 

The  advantage  of  being  able  to  do  this  in  the  case  that 
the  system  has  not  been  fully  validated  is  self-evident. 
There  remain,  though,  advantages  even  when  the  system  has 
been  demonstrated  secure.  i.e.«  even  when  we  Know  that  the 
penetration  attempt  is  doomed  to  failure.  For  one  thing, 
we  are  catching  an  individual  who,  if  not  caught,  might  go 
on  to  penetrate  another,  mere  vulnerable  system. 

Secondly,  a validated  system  is,  in  our  meaning,  simply 
one  whose  security  (at  least  in  the  sense  of  satisfying 
the  ^-property)  has  been  proved.  This  does  not  imply  a 
general  “correctness  of  program",  i.e.,  that  the  system 
has  al I good  properties.  So  the  penetrator,  though  he  may 
not  be  able  to  gain  access  to  data  he  is  not  entitled  to, 
may  succeed  in  attaewing  the  robustness  of  the  system,  or 
he  may  be  able  to  deny  services  to  ethers. 

£ass  tiac  a.fi  y &&&iQa 

Probably  more  attention  has  been  paid  to  password 
guessing  than  any  other  form  of  surveillance  [13].  There 
are  perhaps  two  reasons  for  this.  The  first  is  that 
accountability  mechanisms  fail  orastically  if  it  is 
possible  to  Impersonate  beyond  cistinction  a more  privi- 
leged user.  This  need  not  be  true.  There  could  be  nested 
passwords  (or  even  other,  more  complicated,  behavioral 
prerequisites)  demanded  before  the  granting  of  deeper 
privileges.  In  a theoretical  sense,  this  only  changes  the 
probability  of  good  guessing.  But,  assuming  the  system 
storage  of  these  "Keys"  is  itself  secure,  such  a system 
would  certainly  provide  practical  protection  against 
serious  impersonation  attempts  except  those,  of  course, 
based  on  information  yielced  by  the  privileged  user. 

The  other  main  reason  for  concentrating  on  the 
detection  of  password  guessing  as  a surveillance  goal  is 
that,  in  most  systems,  the  penetrator  has,  before  he  logs 
on,  only  the  weaKest  resources  available.  He  cannot,  for 
example,  run  a machine  language  program  designed  to 
subvert  both  the  surveillance  of  his  operations  and  the 
security  of  certain  sensitive  data.  He  must  deal  with  the 
system  at  the  highest,  system  command  level  and  therefore 
where  it  is  best  equipped  to  protect  Itself. 
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Our  feeling  Is  that  the  auditing  of  all  incorrect 
passwords  and  simple  protective  routines*  e.g.*  temporary 
withdrawal  of  all  privileges  to  any  user  whose  password 
appears  to  be  under  attack  (though  frought  with  integrity 
problems)  certainly  makes  sense  but  is  not  likely  to  catch 
the  dangerous  fish. 

Sallee  Q.ttai£tuQ3 

One  of  the  deepest  problems  in  security  preservation 
on  a multi-security-level  computer  system  is  the  possi- 
bility that  a Trojan  horse  might  be  able  to  transmit 
highly  classified  information  to  a '■listener”  program  of 
low  security  clearance  by  channels  which  do  not  represent 
formal  violations  of  the  ^-property.  That  is*  though  the 
system  has  been  validated  in  the  sense  that  it  has  been 
proved  the  "listener"  cannot  gain  read  access  to  the  data, 
it  may  be  possible  for  the  Trojan  horse  to  communicate 
through  what  are  known  as  covert  channels  [14].  Practical 
steps  can  be  taken  to  minimize  such  a danger.  One  could* 
for  example*  respond  to  all  I/O  requests  in  a uniform, 
"maximum"  time  ano  maintain  separate  process  time  queues* 
if  not  for  each  user,  then  for  each  security  classifica- 
tion. There  are  two  problems  inherent  in  such  an 
approach.  The  first  is  that  the  penalty  in  system  perfor- 
mance associated  with  such  a strategy*  unlike  that 
(currently  estimated  as  a few  percent)  associated  with 
♦-property  satisfaction*  might  be  quite  unbearable.  The 
second  problem  is  that  the  criterion  we  are  asking,  ylz* 
that  no  such  channel  remains,  is  rather  less  precise  than 
the  extremely  simple  *-property  and  may  prove  a great  deal 
more  difficult  to  demonstrate  formally. 

One  response  sometimes  made  to  this  problem  is  that 
any  such  Trojan  horse  must  set  up  a peculiar  behavior 
Pattern  that  could*  perhaps*  be  detected  by  the  surveil- 
lance apparatus.  Perhaps.  The  use  of  software  surveil- 
lance techniques  is  discussed  in  a later  section. 


ACTIVE  DEFENSES 

It  has  been  suggested  that,  associated  with  the 
surveillance  system,  there  coula  be  mere  active, 
entrapment  procedures  whose  goal  is*  by  apparently 
yielding  to  the  penetrator,  to  catch  him  and/or  to  lead 
him  into  innocuous  pathways.  Some  study  of  this  possi- 
bility has  been  pursued  by  0.  Hollingsworth  [15]  of  the 
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Rand  Corporation.  Me  shall  discuss  this  Idea  at  greater 
length  In  Section  IV. 


ASSESSMENT  OF  PRIOR  DAMAGE 

The  main  function  of  the  audit  log  Is  to  serve  as  the 
electronic  counterpart  to  the  familiar  security  systems 
employed  for  the  control  of  top  secret  Information  in 
paper  form.  Each  copy  of  a classified  object  Is  to  be 
registered  in  the  custody  of  a particular  individual  ana 
all  transfers  of  custody  and  object  destructions  are  to  be 
carried  out  according  to  established  procedures.  Should 
any  breach  of  security  regulations  occur,  there  Is  a clear 
Initial  point  for  the  assignment  of  guilt. 

However,  particularly  in  the  case  of  a non-va 1 1 dated 
monitor,  one  would  hope  thet  the  system  security  officer 
could  use  the  on-line  facilities  for  examining  the  audit 
log  for  clues  to  possible  attempts  at  penetrating  the 
system.  It  would  be  especially  useful,  in  case  there  was 
evidence  of  a successful  penetration,  to  be  able  to  try  to 
paste  together  a picture  of  Just  which  data  was 
compromised  and  by  what  means. 

One  malor  problem  may  turn  out  to  be  not  a lack  of 
Information  but  a surfeit  of  It.  The  security  manual 
cited  previously,  0o3  5200. 28-M,  while  specifying  that 
records  be  kept,  e.g.,  “each  access  to  a classified  file 
and  the  nature  of  the  access",  does  contain  the  escape 
c I ause  * 

b.  The  potential  nears  by  which  a computer  system 
can  be  adequately  secured  are  virtually  unlimited. 

The  safeguards  adopted  must  be  consistent  with  avail- 
able technology,  the  frequency  of  processing,  the 
classification  of  the  data  handled  or  the  information 
to  be  produced,  the  environment  in  which  the  AOP 
System  operates,  the  degree  of  risk  which  can  be 
tolerated,  and  other  factors  which  may  be  unique  to 
the  installation  involved.  Rigid  adherence  to  all 
techniques,  methodologies,  and  requirements  discussed 
in  this  manual  could  adversely  lepact  upon  the 
present  and  future  use  of  the  system  under  today’s 
rapidly  changing  ADP  technology.  This  technology  Is 
dynamic  ana  the  methods  chosen  to  secure  a particular 
system  must  accommodate  new  developments  without 
degrading  the  level  of  protection. 
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c.  The  techniques,  methodologies*  and  procedures  in 
this  manual*  however*  represent  an  approved  method  of 
securing  a remotely  accessed  resource-sharing 
computer  system  in  a nulti-level  security  mode  as 
prescribed  by  DoD  Directive  52CQ.28,  “Security 
Requirements  for  Automatic  Oata  Processing  fAOP) 
Systems”*  December  i8,  1972.  It  is  understooc  that 
all  of  the  techniques  describee  in  this  manual  may 
not  be  economically  Justified  after  a cost  versus 
risk  evaluation.  Therefore,  selected  subsets  of  the 
techniques  included  in  this  manual,  with  appropriate 
trade-offs,  may  be  used  to  gain  the  level  of  security 
required  for  classification*  category,  etc.*  to  be 
secured.  In  addition,  techniques  not  necessarily 
included  in  this  manual  may  be  used  so  long  as  such 
methods  provide  the  oegree  of  security  specified  in 
DoD  Directive  52CC.28* 

He  have  already  mentionea  that  it  would  be  necessary 
to  exempt  the  attempts  at  prohibited  data  accesses  by  the 
"subverter"  from  being  entered  in  the  audit  log.  There 
will  no  doubt  be  othar  exceptions*  but  we  would  still 
expect  the  cumulative  contents  of  the  audit  log  to  take  on 
mammoth  proportions.  As  a result  we  feel  that  the  system 
security  officer  must  be  provided  on-line  tools,  not  Just 
to  set  flags  that  determine  which  classes  of  events  are 
logged,  but  also  convenient  tools  for  the  selection, 
editing,  and  correlation  of  that  data  which  is  preserved. 
These  tools  should  Include  a small  language  allowing  him 
to  form,  a?  the  least,  boolean  combinations  of  conditions, 
somewhat  similar  to  the  facilities  provided  by  conven- 
tional text  search  systems. 

Incidentally,  the  audit  log  will  not  be  the  sole 
source  of  clues  useful  in  damage  assessment.  Damaged 
directories  might,  for  example,  help  establish  a trail 
pointing  at  data  whose  security  is  suspect. 


ACCIDENT  PREVENTION  AND  DETECTION 

The  security  officer  of  any  Installation  deallnq  with 
classified  material  must  spend  almost  all  his  time 
concerned  with  the  accidental,  non-ma  1 1 c i ou s failure  to 
protect  classified  information  according  to  regulations. 
Only  a very  small  percentage  of  his  activities  are 
Involved  with  the  actual  disclosure  of  information,  even 
accidental  disclosure.  As  for  purposeful  espionage,  most 
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security  officers  must  surely  serve  their  entire  tour  of 
duty  without  ever  once  coming  into  contact  with  such  an 
inclaent.  We  should,  in  general,  expect  that  accidental 
infractions  would  also  oreoominate  for  multi-security 
level  computer  systems.  The  occurrence  of  willful  cene- 
tration  attempts  are  higher  in  industrial  and,  especially, 
commercial  applications  where  they  often  represent 
monetary  theft  [16].  They  may  also  be  somewhat  higher 
than  we  have  Been  accustomed  to  in  those  military  computer 
applications  that  present  sufficiently  tempting 
concentrations  of  information.  Nevertheless,  accidental 
infractions  will  always  predominate  and  each  must  be 
treated  as  a possible  disclosure  ana  a certain  nuisance. 

One  of  the  most  practical  functions  of  the  system 
security  procedures,  inclucing  those  of  audit  and  surveil- 
lance, is  to  minimize  the  occurrence  of  such  infractions 
anc  to  correctly  calculate  the  consequences  of  any  that  do 
occur.  The  software  orocecures  should,  in  fact,  be  much 
more  effective  than  the  control  of  printed  reports  since 
each  data  structure  is,  unless  converted  to  "output", 
under  the  continual  control  of  the  programs  responsible 
for  security.  That  is,  rather  than  fearing  the  security 
problems  associated  with  itu  I t i- secur  i ty  level  computer 
systems,  we  should  perhaps  realize  that  truly  validated 
systems  are  much  safer  repositories  of  classified  aata 
than  those  based  on  the  normal  procedures  for  handling 
such  data  in  paper  form. 

Software  bugs  can  lead  to  attempts  at  il  legal  memory 
references.  The  combination  of  a validated  Kernel  and  a 
program  to  continually  check  the  hardware  protection  mech- 
anisms ensures  that  any  such  accidental  reference  cannot 
access  aata  to  which  the  process  is  net  entitled.  In 
unverified  systems,  some  of  this  burden  must  be  passed  to 
the  audit  system  which  would,  at  least,  record  any  such 
access.  Another  important  use  of  the  audit  system  is  to 
record  any  accidental  disclosures  of  information  stemming 
from  conscious  decisions  to  relax  the  ♦-property,  e.g., 
those  discussed  above  in  reference  to  either  the  debugging 
of  unverified  software  operating  on  classified  data  bases 
or  the  downgrading  of  classified  material. 
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SECTION  III 


CONSTRAINTS 


Since  we  hope  this  report  eight  serve  as  a partial 
checklist  in  the  contracting  and  design  of  the  audit  and 

surveillance  apparatus  of  multi-level  systems*  it  is 
imperative  that  me  discuss  not  Just  the  purposes  of  audit 
and  surveillance  and  the  possible  strategies  for  implemen- 
ting them  but  also  the  constraints  that  may  function  to 
restrict  those  strategies. 


PRIVACY 

In  an  abstract  sense*  privacy  anc  security  are  the 
same  problem.  Our  methods  for  the  mathematical  modeling* 
specification*  and  validation  of  security  kernels  are 
sufficiently  general  to  enforce  many  privacy  policies. 
Security  levels  define  a partial  ordering  for  each  type  of 
access  (read*  read-mrite*  execute*  etc.)  and  everything 
that  me  have  done  abstractly  is  dedicated  to  the  integrity 
of  that  partial  ordering.  Our  methodology  mould  remain 
valid  mere  me  to  employ  a different  (privacy  instead  of 
security)  policy  to  define  that  ordering. 

Homever*  from  a practical  point  of  viem,  almost 
everything  me  have  been  saying  about  the  audit  and 
surveillance  assumes  that  in  our  instantiation  of  this 
model*  there  mill  almays  be  a maximal  element  mith  access 
to  all  on-line  information.  That  element*  of  course*  is 
called  "the  system  security  officer".  While  me  seem  quite 
dependent  on  this  "supti — maximal"  element*  its  existence 
appears  in  contradiction  to  any  enacted  or  proposed 
civilian  privacy  policies  [17]. 

The  existence  of  a maximal  element  presents  no 
problem  as  long  as  me  are  concerned  mith  pjrely  military 
systems  operating  completely  mithln  OoD  regulations.  A 
problem  mould  only  arise  if  the  Defense  Department  mere  to 
find  advantages  in  sharing  a multi-level  secure  system 
mith  uncleared  civilian  users*  e.g.»  those  at  a univer- 
sity. Under  such  circumstances,  the  non-existence  of  the 
system  security  officer  (or,  in  more  realistic  terms*  a 
redefinition  of  his  prerogatives),  may  not  be  the  only 
constraint  placed  on  our  security  system.  In  particular. 
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certain  portions  of  the  audit  log  and  surveillance  capa- 
bilities nay  become  prohibited  in  themselves*  independent 
of  mho  may  access  them. 


PERFORMANCE 

Enough  evidence  has  been  derived  from  the  AFDSC 
Multics  --  its  security  mechanisms  being  sufficiently 
similar  to  that  of  s true  Kernel  --  tc  Know  that  basic 
monitoring  of  all  memory  references  will  probably  impose 
an  inconsequential  loss  in  performance*  perhaps  less  than 
l'/.  in  system  response  time.  Such  a statement  must  assume 
a virtual  environment  in  which  we  are  already  paying  the 
expense  of  virtual  addressing,  but  that  would  seem  a fair 
assumption  as  long  as  we  are  sbeaKing  of  future  computer 
utilities.  Most  systems  Keep  a log  of  some  transactions. 
Almost  all,  for  example*  record  logins  and  logouts  and 
requests  for  outputs  as  well  as  cumulative  figures  related 
to  the  charging  algorithms*  e.g.,  CPU  time,  1-0  usage, 
etc.  But,  what  we  believe  to  be  the  first  system  capable 
of  recording  all  unqualified  attempts  at  segment  access* 
that  of  the  Air  Force  Data  Services  Center,  is  only  now 
becoming  operational.  He  have  no  evidence  as  to  the  toll 
the  requirement  for  auditing  all  segment  accesses  will 
taKe  of  the  system  performance.  He  would  not  be  surprised 
to  learn  that  it  proved  necessary  to  relax  some  of  these 
requirements.  Finally*  all  surveillance  techniques*  e.g., 
"pattern  matching"  or  "entrapment,"  must  also  be  sub)ected 
to  analyses  in  terms  of  their  impacts  on  system  perfor- 
mance. 


COST  EFFECTIVENESS 

The  expense  of  any  suggested  audit  or  surveillance 
system  must  be  weighed  against  its  benefits.  Of  course* 
any  of  the  items  discussed  above  which  adversely  affect 
performance  must  also  detract  from  the  system’s 
cost-effectiveness.  But  we  are  concerned  here  more  with 
fixed  costs.  These  must  include  the  design  and  implemen- 
tation of  the  audit  software.  For  certifiable  systems,  we 
must  add  the  cost  of  verification  and  for  non-cert  i f lab  le 
systems*  that  of  testing  for  any  parts  of  the  audit  mecha- 
nism that  must  be  trustworthy. 

In  addition*  we  must  be  concerned  with  installation 
costs.  The  Keeping  of  very  extensive  audit  logs  may 
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require  an  extra  disc  drive  and  the  long-term  storage,  both 
extra  tape  drives,  and  an  enormous  tape  library. 
Furthermore,  extra  computer  room  personnel  may  be  needed 
for  maintaining  these  records  and  the  office  of  the 
computer  security  officer  cay  have  to  be  expanded  to 
provide  assistance  in  the  surveillance  and  evaluation  of 
al  I this  data. 


INTEGRITY 

It  is  possible  that  there  are  some  conflicts  between 
integrity  and  security.  For  example,  the  desire  that  no 
person  or  event  may.  whether  accidentally  or  purposefully, 
destroy  important  data  or  programs  argues  for  the  exist- 
ence of  multiple  copies,  even  in  physically  separated 
locations.  Security  considerations  would,  to  the 
contrary,  argue  for  a single  copy,  limited  to  on-line 
storage  where  it  is  always  subject  to  our  verifiable 
protection  mechanisms.  It  is  not  so  easy  to  think  of  a 
conflict  between  integrity  and  audit  or  surveillance 
considerations,  but  we  are  including  "integrity**  in  our 
checklist  for  fear  we  have  not  thought  it  out  suffi- 
c i ent I y . 


FLEXIBILITY 

What  happens  to  a validateo  system  when  you  need  to 
modify  it?  Our  techniques  for  demonstrating  the 
Msecur i ty-correctnesi“  of  a kernel  are  predicated  on  a 
hierarchical  design  technique  to  be  exploited  for  purposes 
both  of  sped  f leaf  1 on  and  verification.  This  hierarchical 
structure  would  also  be  an  aid  should  any  modification  of 
the  system  become  necessary.  It  is  hard  to  say  how  likely 
such  changes  are.  On  the  one  hand,  the  difficulties  in 
proving  a system  correct  might  tend  tc  motivate  the 
kernel's  being  well-defined  up  to,  perhaps,  the  setting  of 
system  parameters.  This  would  imply  a trade-off  (at  least 
until  verification  techniques  become  less  burdensome)  in 
favor  of  less  flexibility  and,  consequently,  we  might  well 
expect  future  changes.  Each  such  change  woul d carry  the 
burden  of  a new  proof  of  correctness,  supported  hopefully 
by  the  invariance  of  various  hierarchical  layers  in  the 
previous  proof.  Nonetheless,  it  would  represent  a burden. 
On  the  other  hand,  to  the  degree  we  manage  to  bound  the 
functions  of  the  kernel,  the  more  likely  will  the  chanqes 
that  occur  be  external  to  the  verified  code. 
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What  does  this  have  to  do  with  audit  and  surveil- 
lance? First  and  foremost,  some  parts  of  these  systems 
must  be  within  the  Kernel.  This  is  Implied  Py  these 
systems  having  the  right  ard  duty  to  monitor  attempts  to 
access  ever^  segmenw  Such  partial  inclusion  within  the 
Kernel  implies  flexiWlity  on  the  design  of  the  audit 
mechanisms. 

With  regard  to  the  portions  of  the  audit  and  surveil- 
lance systems  outside  the  Kernel,  the  impact  of  this 
problem  is  probably  little  more  than  the  ooservation  that 
it  would  pay  to  design  these  portions  flexibly  so  as  to  be 
oreparea  to  accept  Kernel  changes  gracefully. 
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SECTION  IV 


STRATEG  IES 


The  purpose  of  this  section  Is  to  discuss  a number  of 
means  that  might  be  employed  to  achieve  the  goals  of 
Section  II  subject  to  the  constraints  of  Section  III. 


BASIC  AUOIT 

Though  possibly  relievea  by  an  escape  clause  (see 
page  18),  Section  V of  OoD  520C.28-M  demands  that  we  main- 
tain an  audit  log  which  records* 

1.  each  login; 

2.  each  creation  of  a new  classified  file  (for 
MULTICS*  read  segment); 

3.  each  access  to  a classified  file  (for  Multlcs* 
read  initiation  of  a classified  segment)  and  its 
nature;  and 

4.  each  production  of  accountable  classified 
output . 

We  could  also  add  as  possibilities* 

5-8.  each  failed  attempt  at  i-4  above*  with  reason 
for  denia I ; 

9.  each  update  of  a file  (segment); 

IQ.  each  chanye  of  access  privileges* 

11.  each  change  to  a directory? 

12.  each  change  of  audit  type? 

13.  each  attempted  “ring**  violation? 

14.  certain  operator  actions*  e.g.,  changing  system 
configuration  or  parameters? 
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15.  each  destruction  of  a classified  file* 

16.  each  deliberate  "-property  violation*  e.g.« 
downgrading* 

17.  each  effective  action  of  the  system  security 
officer? 

18.  each  change  of  monitor  version? 

19.  each  alarm  to  the  system  security  officer  from 
any  surveillance  program? 

2G  • each  detected  hardware  failure? 

21.  each  system  crash? 

22.  statistics  on  user  resource  consumption. 


Care  should  be  taken  in  the  basic  audit  of  the  system 
to  identify  and  record  the  minimum  amcunt  of  information. 
It  is  easy  to  postulate  an  audit  system  that  records  so 
much  information  that  the  timely  selection  of  interesting 
data  is  impossible.  Thus  the  choice  of  data  and  the  tools 
to  analyze  the  data  are  Important. 

The  audit  system  comprises  both  the  logging  mechanism 
that  records  some  subset  of  the  above  items  and  the  soft- 
ware available  to  the  system  security  officer.  This  soft- 
ware is  of  two  types.  The  first  provides  the  security 
officer  control  over  the  auditing  process  by  allowing  him 
to  choose  (a)  which  events  are  audited  for  <bl  which 
processes/users.  He  must*  as  a minimum*  be  capable  of 
turning  off  the  monitoring  of  faults  associated  with  the 
program  that  maintains  a continual  check  on  the  haroware 
protection  mechanisms.  This  control  over  the  subverter 
program  could  be  satisfied  by  the  capability  of  assigning 
each  process  an  overall  audit  type  that  decides  whether 
all  its  auditable  actions  are  recorded  in  the  audit  log. 

It  might  be  more  useful  to  associate  with  each  process* 
not  an  audit  bit*  but  an  audit  vector  that  decides  the 
logging  of  each  type  of  audit-worthy  event  independently. 

The  second  type  of  audit  software  comprises  the  tools 
provided  to  the  security  officer  for  the  analysis  of  the 
recordea  data.  This  must  include  tools  for  searching  the 
voluminous  records  for  events  satisfying  security  officer 


defined  predicates  and  probably  should  include  others  for 
the  correlation  of  such  events.  This  software  should  be 
augmented  in  response  to  the  security  officer’s  needs  as 
they  develop  in  light  of  experience  with  the  audit  soft- 
ware and  the  event  patterns  of  the  entire  system. 


SURVEILLANCE 

Besides  more  esoteric  surveillance  strategies  such  as 
"pattern-matching"  or  entrapment  discussed  below,  the 
security  officer  shoulc  oe  provided  some  simple  software 
that  he  can  use  to  observe  security-related  events  while 
they  are  in  progress.  This  software  might  include  alarm 
systems  that  call  his  attention  to  patent  attempts  at 
password  guessing  or  to  especially  high  frequencies  of 
attempted  protection  violations,  on  the  assumption  that 
such  high  frequency  events  may  represent  malicious  intent. 
The  software  should  associate  specific  terminals  and  proc- 
esses with  the  suspicious  activity. 

Me  would  also  expect  the  security  officer  to  have,  at 
least  in  those  circumstances  in  which  there  is  no  privacy 
constraint,  a Big  Brother  capability  of  selectively  tuning 
in  on  various  processes  anc  events,  watching  them  in  prog- 
ress, reading  information  as  it  is  upcated,  noting 
resource  requests,  intercepting  interprocess  communica- 
tion, etc.  This  would  all  represent  a rather  basic  spying 
facility  with  little  in  the  way  of  aata  processing  aids  to 
help  refine  and  correlate  the  evidence.  Such  correlation 
alas  would  be  part  of  the  more  soohis ticated  strategies 
discussed  below. 


MULTIPLE  ENTRY  INFORMATION 

Information,  whether  we  thlnK  cf  it  as  data,  or  the 
value  of  state  variables,  or  entries  in  directories  or 
access  control  lists,  or  system  parameters,  can  be  stored 
in  several  locations  that  can  be  cheched  for  consistency. 
This  redundant  storage  has  some  attraction  as  a surveil- 
lance tool  for  the  discovery  of  would-be  perpetrators.  In 
the  case  of  non-cer t 1 f 1 ed  systems,  such  redundancies  can 
also  provide  an  extra  layer  of  protection. 

Protection  would  come  from  secrecy,  l.e.,  from  the 
fact  that  attempts  to  penetrate  on  the  basis  of  experiment 
and  deduction,  in  ignorance  of  a complete  system  descrip- 
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tion,  Mould  be  very  unlikely  to  put  the  pieces  together. 
This  unlikelihood  can  be  arbitrarily  Increased  by  Imposing 
not  a simple  repetition  of  data  but  by  the  Imposition  of 
an  arbitrarily  complex  relation  among  the  various  data 
elements.  Particularly  sensitive  information  may  be 
protected,  even  against  spies  kith  a knoMledge  of  the 
system,  by  making  this  “key**  relationship  subject  to  priv- 
ileged updating. 

An  auxiliary  advantage  of  such  redundancy  is  the 
protection  It  lends  the  integrity  of  system  against 
errors,  particularly  on  the  part  of  the  operator  and  the 
system  security  officer. 

Beyond  the  use  of  such  redundancy  for  the  protection 
of  system  (and  user)  Integrity  and  for  additional  security 
protection  In  non-cer t 1 f 1 eC  systems,  the  Imposition  of 
calculable  relations  among  information  items  can  serve  as 
an  important  audit  and  surveillance  tool.  All  actions 
that  are  denied  because  of  the  Inconsistency  of  such  data 
can  be  recorded  In  the  audit  log  |ust  like  any  other 
attempt  at  a protection  violation.  Furthermore*  a system 
program  could  move  through  the  active  processes  making 
spot  checks  on  the  consistency  of  these  items  even  when 
that  consistency  Is  not  reoulrec  by  the  user  for  the 
exercise  of  particular  privileges.  After  making  some 
allowance  for  the  fact  that  the  redundant  items  cannot  be 
changed  simultaneously,  the  discrepancies  could  be  brought 
to  the  attention  of  the  security  officer. 


PATTERN  RECOGNITION  ANO  STATISTICAL  STUDIES 

One  of  the  techniques  often  suggested  for  the 
surveillance  of  multi-level  secure  systems  is  the 
real-time  search  for  suspicious  patterns  of  behavior  on 
the  part  of  particular  processes.  There  is.  first  of  all. 
the  superficial  behavior  patterns  associated  with  password 
guessing  or  attempts  to  access  prohibited  directories  or 
access  control  lists.  Another  target  of  these  proposed 
pattern  matching  techniques  are  the  mere  sophisticated 
attempts  at  the  theft  of  classified  data  by  “Morse  Code". 
The  situation  we  fear  is  that  a "Trojan  horse",  e.g..  an 
untrusted  utility  program,  being  used  to  process  classi- 
fied data  could  manage  to  "telegraph"  classified  informa- 
tion to  an  unclassified  (or  lower  classified)  "listener" 
program.  That  is.  the  Trcjan  horse  might  try  to  set  up  a 
pattern  of  behavior,  e.g.,  a time-sequence  of  resource 
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(virtual  memory,  1-0  facilities*  etc.)  utilization  or 
saturation  that  could  be  monitored,  admittedly  in  the 
oresence  of  noise*  by  the  listener  program.  The  reception 
process  might*  for  example*  be  baseo  upon  denials  of 
listener  requests  for  the  same  resources.  In  a recent 
informal  experiment  at  MIT,  the  Multics  paging  mechanism 
was  employed  to  telegraph  a message  at  the  rate  of  about 
one  character  per  second  with  about  a bit  error  rate  of 
108-29*  In  some  more  "paranoid"  scenarios*  the  Trojan 
horse  is  imbedded  in  the  hardware. 

The  hope  expressed  by  advocates  of  pattern-matching 
surveillance  techniques  is  that*  since  the  telegraphed 
message  is  Imposing  a patterned  behavior  on  an  otherwise 
random  sequence  of  everts,  that  same  fact  might  be 
exploited  for  the  detection  of  the  Trojan  horse.  To  our 
Knowledge*  nothing  has  really  been  done  to  substantiate 
this  possibility.  The  fact  that,  as  viewed  by  the  system, 
normal  resource  requests  arrive  ranoomly  hardly  implies 
that  their  arrivals*  especially  --  and  this  is  the  Ques- 
tion --  their  arrivals  from  a particular  benign  process* 
are  uncorrelated.  In  order  to  send  a message,  the  event 
spectrum  of  the  Tro|an  horse  must  be  different  than  that 
of  normal  system  use.  But  it  would  always  be  possible  to 
build  a counter-counter  response  to  spectral  surveillance 
by  arbitrarily  lowering  the  bandwidth,  i.e.,  maKing  the 
telegraph  channel  appear  more  like  benign  behavior  at  a 
cost  of  lower  information  transmission  rates.  We  must 
further  keep  in  mind  that  the  surveillance  program  would 
normally  be  trying  to  detect  the  Trojan  horse  among  all 
active  classified  processes  in  complete  ignorance  of  the 
techniques  and  code  employed  or  even  the  Trojan  horse’s 
ex i s tence. 

We  would  like  to  suggest  that  the  most  reasoned 
aporoached  to  the  question  of  pattern  matching  surveil- 
lance methods  is  to  gain  a better  understanding  of  the 
possibilities  through  the  collection  of  event  statistics 
and  the  performance  of  simple  experiments  on  systems  such 
as  Multics. 


The  objects  on  which  we  might  wish  to  collect 
statistics  tall  into  two  classes,  depending  on  whether  we 
are  trying  to  detect  an  external  lock-picking  attempt  at 
system  penetration  or  an  internal  Troian  horse  telegraphy 
of  information  to  a listener.  In  the  first  case,  we 
expect  the  intruder  to  be  revealed  by  the  illegality  of 
his  moves.  The  objects  we  woul  c be  Interested  in  would 
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Include  elementary  events  such  as  illegal  Instructions 
(particular  I y attempted  ring  violations  in  Multlcs)  and 
illegal  addresses.  These  latter  mould  primarily  be  due  to 
segment  violations*  e.g.t  requests  for  non-existent 
segments*  or  segments  to  which  the  user  is  prohibited 
access  (particularly  to  system  directory  or  tabular  infor- 
mation) or  to  which  he  has  access  privileges*  but  of  a 
different  type.  All  of  these  statistics  should  be  Kept  in 
rather  fine  detail.  System  tables  are  to  be  distinguished 
from  other  protected  segments*  ring  violations  are  to  be 
classified  by  ring*  segment  denials  by  reason  of  security 
level  are  to  be  distinguished  from  those  due  to  need-to-- 
knom,  i.e.*  discret  ionary  * privileges.  Similar  statistics 
would  also  be  Kept  for  non-virtual  entities*  e.g.*  denials 
of  off-line  printouts. 

Besides  these  elementary  events*  me  mould  also  record 
statistics  on  some  compound  events  that  appear  Indivisible 
to  system  users.  These  mould  include  all  logon  failures 
whether  caused  by  non-aut hor i zeo  personal  identification* 
invalid  project  or  group  association*  incorrect  passmoro* 
a request  for  too  high  a security  level  or  an  attempt 
either  to  log  on  at  a personally  valid  security  level  from 
a terminal  which  is  not  physically  secured  at  that  level 
or  an  attempt  to  logon  at  any  level  on  a terminal  whose 
physical  security  exceeds  the  user's  clearance.  The  last 
represents  a breach  of  physical  security  and  must  invoke 
an  immediate  alarm. 

Much  of  the  above  material  mill  be  recorded  in  the 
audit  log  in  any  case.  We  are  only  suggesting  that  a 
little  statistical  data  processing  might  help  us  determine 
if  any  proposed  surveillance  scheme  has  much  chance  of 
detecting  external  penetration  threats. 

With  regard  to  the  internal*  Trojan  horse*  threats* 
on  the  other  hand*  it  mould  seem  necessary  to  carefully 
design  specific  experiments.  Unlike  the  items  mentioned 
above  which  are  (though  most  frequently  by  accident  rather 
than  design)  patent  attempts  to  transgress  the  system's 
security  boundaries*  the  Trojan  horse  is  employing  normal 
system  components  in  apparently  normal  modes  and  never 
violates  any  formal  protection  mechanisms.  We  have*  in 
fact,  very  little  to  look  for,  |ust  unlikely  patterns  in 
the  demands  placed  on  deep  system  resources*  e.g.,  the 
oaging  mechanism  or  the  1-0  channels  or  devices. 


For  both  the  internal  and  external  threats*  the 
statistics  collected  for  each  of  the  listed  items  must 
include  its  mean  (i.e.*  the  volume  of  transactions)*  its 
variance  (i.e.*  the  peculiarity  of  special  events)*  and 
certain  correlations.  These  would  include  correlations 
between  different  events*  between  events  aid  processes* 
and  between  events  and  users.  This  list  is  needed  for 
both  the  discounting  of  personal  idiosyncrasies  and  for 
the  association  of  a Trojan  horse  with  a listener. 

In  the  case  of  the  internal  Trojan  horse  threat*  we 
must  also  collect  the  critical  data  on  the  frequency 
spectra  of  calls  and  saturation  of  the  system  components. 
Furthermore*  we  must  Investigate  what  sort  of  time  changes 
are  to  be  expected  in  these  spectra*  since  such  events* 
being  normally  so  dependent  on  system  load*  could  hardly 
constitute  stationary  processes. 

Any  potential  criteria  for  the  discovery  of  a Trojan 
horse  that  might  emerge  from  these  studies  should  be 
tested  experimentally  against  Trojar  horses  we  have  foaled 
ourselves.  These  tests  should  be  run*  presumably  on  a 
Multics  system,  under  both  heavy  and  light  loeds  by 
parties  blind  to  the  presence  or  absence  of  the  Trojan 
horse.  Furthermore,  these  tests  must  be  designed  to 
reveal  clearly  their  dependence  or  independence  of  both 
the  actual  techniques  employed  by  particular  Trojan  horses 
and  the  Knowledge  of  these  techniques. 


ACTIVE  DEFENSES 

As  previously  referenced*  Ho  1 1 ingswort h advocates  the 
use  of  active  defenses*  i.e.*  pseudo-flaws  combined  with 
entrapment  tactics*  designed  to  lead  a would-be  penetrator 
away  from  system  weaKnesses  into  a oath  on  whlcn  he  seems 
to  be  gaining  prohibited  accesses*  but  is*  in  fact,  beinq 
misled  and  monitored. 

At  the  system  command  or  text-editor  level*  the 
scenario  would  have  the  user  guessing  passwords*  being 
rejected  several  times*  then  finally  being  accepted.  The 
user  then  tries  to  reao  privileged  oata  and,  while 
apparently  succeeding*  is*  in  fact,  fed  false  data  from 
prepared  files.  With  respect  to  lower  level  attempts  at 
penetration*  e.g.,  prohibited  memory  references  generated 
by  user  defined  assembly  language  routines,  the  strategy 
is  for  the  illegal  instruction  to  trap  to  a software 
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routine  which  sets  uo  a pattern  of  misleading  behavior 
rather  than  the  normal  program  abort.  From  the  moment  his 
behavior  becomes  so  suspicious  as  to  invoke  the  entrapment 
process,  the  user  would  not  be  only  subject  to  the  normal 
audit  and  surveillance  procedures,  but  would  also  be  moni- 
tored so  that  an  alarm  would  be  sounded  and  a real-time 
transcript  of  the  entire  user-machine  conversation 
preserved. 

One  must  be  skeptical.  All  concern  about  password 
guessing,  whether  in  reference  to  entrapment  or  pattern 
matching  surveillance  techniques,  must  raise  the  question 
as  to  whether  such  tactics  constitute  any  substantial 
threat.  Since  most  systems  give  the  user  no.  or 
practically  no.  resources  until  logged  on,  he  can  do 
little  but  guess  wildly.  Cur  real  threats  are  from  much 
more  sophisticated  users  who  hope,  in  fact,  to  employ  the 
extensive  on-line  system  facilities,  turning  them  to  their 
own  advantage.  Any  sophisticated  user  who  found  he  could 
reference  prohibited  segments  through  the  sole  use  of  such 
high  level  facilities  as  a text-editor  would  be  very 
suspicious  indeed. 

Still,  if  one  could  provide  convincing  active 
defenses,  the  advantages  woulc  be  quite  attractive. 
Hollingsworth  advocates  entrapment  as  an  additional 
defensive  mechanism  for  non-cer t i f i ab I e systems.  But, 
catching  a thief  is  interesting  in  itself,  and  catching  a 
spy  much  more  valuable.  So  there  would  be  strong  motives 
to  add  such  facilities  to  certified  systems  also.  Active 
defenses  have  the  further  attraction  that  they  not  only 
trap  the  culprit  in  the  act,  but  they  also  go  a long  way 
towards  establishing  his  intent.  One  must  be  extremely 
skeptical,  however,  about  the  machine's  ability  to 
understand  the  user's  motives  enough  to  convincingly 
entrap  him  when  the  total  evidence  of  his  intentions  is 
imbedded  in  an  arbitrary  assembly  language  program. 
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SECTION  V 


RECOMMENDATIONS 


The  discussion  to  this  point  indicates  that,  in 
general,  the  auait  of  mu  I t i-secur it y-  level  systems  is 
fairly  well  understood  as  is  hardware  surveillance.  The 
proposed  approaches  to  software  surveillance,  at  least  the 
more  Imaginative  ones,  are  on  much  less  solid  foundation, 
Me  should  like  in  this  section  to  suggest  guidelines  with 
respect  to  the  study  and  imp  I ementat i cn  of  audit  and 
surveillance  related  subsystems  that  seem  to  us  natural 
and  reasonable  under  these  circumstances. 


ENGINEERING  APPROACHES 

We  refer  here  to  those  tasks  that  are  obligatory  and 
sufficiently  understood  so  that  intelligent  design  is 
possible  today. 

ESO  is  involved  in  the  construction  of  a number  of 
multi-level  secure  systems  which  require  audit  facilities. 
These  would  Include  the  Air  Force  Data  Services  Center 
f2J,  the  Security  Kernel  Based  Multics  System,  the  Secure 
Front-End  Processor  to  Multics,  and  the  POP-ll/45.  The 
audit  logs  required  by  OoO  5200. 28-M  must  include  items 
1-4  of  our  list  of  21  items  at  the  beginning  of  Section 
IV.  Though  the  practicality  of  recording  all  accesses  to 
classified  segments  is  extremely  questionable,  the  facili- 
ties to  satisfy  all  four  requirements  will  exist  in  the 
two  MULTICS  systems  Just  referred  to.  The  syserr  log  of 
the  AF  Data  Service  Center  will  also  contain  records  of 
denied  accesses  and  illegal  procedures  (our  items  7 and 
13).  Most  of  the  other  items  on  our  list  would  also  seem 
well-aovised  and  easy  to  implement. 

In  addition  to  the  actual  logs,  the  system  security 
officer  must  have  available  the  relevant  software 
described  in  Section  IV  for  the  control  of  the  auditing 
process  (the  Data  Services  Center  specification  referenced 
above  describes  "audit  select  flags"  which  are  equivalent 
to  our  "audit  vector")  ana  for  the  on-line  analysis  of 
collected  data.  This  list  includes  the  audit  search  spec- 
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lflcation  language  and  correlation  tools*  Efforts  should 
be  concentrated  In  identifying  and  recording  only  the 
minimum  necessary  data  to  keep  the  data  reduction/analysis 
problem  from  becoming  too  complex* 

The  "subverter",  the  hardware  surveillance  mechanism, 
should  be  included  to  provide  protection  against  probabil- 
istic hardware  failure.  The  operation  of  a subverter  is 
discussed  by  Karger  and  Schell  [12].  The  provision  of  the 
alarm  and  Big  Brother  systems  mentioned  in  Section  IV 
represent  an  additional  surveillance  capability  that  might 
be  a goal  for  future  development. 


DEVELOPMENTAL  APPROACHES 

The  main  prob I em  is  the  evaluation  and  design  of  the 
more  sophisticated  surveillance  techniques*  We  would  like 
to  suggest  that  the  steps  below  be  taken  sequentially. 

Slallslicai-SliidLes 

In  Section  IV*  we  outlined  at  some  length  a proposed 
statistical  study  of  security  related  events.  We  feel 
such  a study  should  be  undertaken  on  some  selected  Multics 
system(s).  It  should  first  be  determined  which  statistics 
are  currently  available  from  extant  Multics  systems*  e.g.» 
MIT*  Honeywell*  RAOC*  AFDSC,  and  then  this  information 
should  be  gathered* 

Incidentally*  during  this  study  statistics  should  be 
kept,  to  the  extent  possible*  on  the  cost  in  machine  time 
and  (implicitly)  capital  equipment  reaulred  for  monitoring 
different  events*  This*  of  course*  would  be  for  the 
purpose  of  gaining  more  precise  understanding  of  the 
performance  and  cost  related  constraints  of  Section  III. 

The  main  point  of  collecting  and  interpreting  the 
statistics  on  security  related  events  is  to  have  them 
available  as  analytical  aids  in  the  feasibility  study  of 
the  more  sophisticated  surveillance  techniques*  especially 
the  pattern  matching  approaches  to  Trojan  horse  detection. 
Trojan  horse  detection  is  Uj£.  most  important  surveillance 
problem  because* 
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1.  The  Trojar  horse  remains*  together,  perhaps, 
with  the  possibility  of  espionage  by  cleared 
personnel,  as  one  of  the  outstanding  problems  in 
complete  computer  security.  This  is  a conse- 
quence of  the  fact  that  horse  code  need  not 
represent  a ^-property  violation,  even  in  certi- 
fied systems. 

2.  We  really  do  not  Know  how  feasible  or  effective 
pattern  matching  techniques  are  likely  to  be  as 
a means  of  Trojan  horse  detection. 

3.  No  other  defense  against  this  threat  has,  to  our 
Knowledge,  been  suggested  other  than  the 
division  of  the  machine*s  resources  to  the 
extent  that  processes  of  different  classifica- 
tion share  nothing.  This  latter  approach  would, 
however,  certainly  defeat  many  of  the  motives 
that  led  to  the  sharing  of  the  machine  in  the 
first  place. 


Approach  Analysis 

Partly  based  on  these  statistical  analyses,  the 
various  advanced  surveillance  techniques,  e.g.«  Pattern 
matching,  active  defenses,  multiple  entry  of  Key  informa- 
tion and  more  sophisticated  data  relations,  should  be 
subjected  to  serious  analyses  to  estimate  their  effective- 
ness against  both  external,  high  level  penetration 
attempts  and  internal,  low  level  ones.  In  addition,  the 
solutions  must  be  analyzed  with  regard  to  their  interac- 
tion with  the  constraints  of  Section  III.  In  particular, 
the  redundant  storage  of  information  described  as  the 
multiple  entry  approaches  must  be  studied  to  establish 
whether  there  is  a midole  ground  between  a solution  so 
complicated  that  it  serves  as  an  impediment  to  the  normal 
use  of  the  system  and  one  so  simple  that  its  effect  is 
negated  by  the  "underground"  circulation  of  a few  macros 
which,  in  effect,  convert  the  multiple  entry  system  into  a 
single  entry  one. 


Q£SlflQ_aad_lJnal£m£QiAtl2fl 

We  are  assuming  the  basic  audit  and  surveillance 
mechanisms  are  to  be  lmplementeo  early.  As  for  the  more 
advanced  surveillance  techniques,  we  are  suggesting  that 
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these  be  postponed  until  the  completion  of  the  above 
studies. 
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